fix: step down when leader is removed from config#584
Conversation
|
Welcome @Qian-Cheng-nju! It looks like this is your first PR to tikv/raft-rs 🎉 |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughLeader nodes removed from the voter set now immediately transition to follower in Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
28ea6b1 to
b13a837
Compare
Signed-off-by: Qian-Cheng-nju <Qian-Cheng-nju@users.noreply.github.com>
b13a837 to
186842e
Compare
|
Thanks, how about porting etcd-io/raft#79 so that we will keep sync with upstream? |
|
Thanks for the pointer! I've updated this PR to port etcd/raft#79 — the step-down behavior is now opt-in via a step_down_on_removal config option(default false) for backwards compatibility. Tests cover both the enabled and default cases. |
Hi, thanks for raft-rs!
I noticed an unimplemented code path in post_conf_change() flagged by TODO comments and put together a fix.
When a leader is removed from the voter set, post_conf_change() sets promotable=false but returns without stepping down. The removed leader continues sending heartbeats, which suppress elections on the remaining voters. This blocks the cluster from electing a new leader until the old one is shut down or partitioned.
The fix makes the removed leader transition to follower immediately. The included test (test_bug_removed_leader_does_not_step_down) demonstrates the issue with a 3-node cluster.
Summary by CodeRabbit
Bug Fixes
Tests